1. Field of the Invention
The present invention relates to methods and apparatus for facilitating on-line processing requests, and more specifically, to a more efficient way to honor CORBA service requests to access existing enterprise applications.
2. Description of the Prior Art
The methods by which companies conduct business with their customers are undergoing fundamental changes, due in large part to World Wide Web technology. In addition, the same technology that makes a company accessible to the world, may be used on internal company networks for conducting operational and administrative tasks.
One of the technologies underlying the World Wide Web is the prospect of using component software technology—the idea of breaking large, complex software applications into a series of pre-built and easily developed, understood, and changed software modules called components—as a means to deliver software solutions much more quickly and at a lower cost The goal is to achieve economies of scale for software deployment across the industry.
DCOM is a proprietary technology of Microsoft Corporation and is only applicable to Windows based applications. Therefore, there is a need for a much more generalized and universal component architecture to accommodate a wide range of hardware and operating system platforms. Common Object Request Broker Architecture or “CORBA” is indeed such an approach. CORBA was developed through the efforts of a number of interested companies and agencies. Thus, CORBA provides a technique for the development of software systems.
This component architecture for building software applications will enable this by: 1) speeding development—enabling programmers to build solutions faster by assembling software from pre-built parts; 2) lowering integration costs—providing a common set of interfaces for software programs from different vendors means less custom work is required to integrate components into complete solutions; 3) improving deployment flexibility—making it easier to customize a software solution for different areas of a company by simply changing some of the components in the overall application; and 4) lowering maintenance costs—isolating software function into discreet components provides a low-cost, efficient mechanism to upgrade a component without having to retrofit the entire application.
A distributed component architecture applies these benefits across a broader scale of multiuser applications. CORBA has several strengths that make it a key technology for achieving this. CORBA works easily with Internet technologies like TCP/IP, the Java language, and the HTTP network protocol, providing “object glue” that will enable business applications to work across the Web. CORBA is also an open technology that runs on multiple platforms.
CORBA has its roots as an alternative to Microsoft's DCOM object technology, which has evolved over the last decade from DDE (Dynamic Data Exchange, a form of messaging between Windows programs), OLE (Object Linking and Embedding, embedding visual links between programs within an application), COM (the Component Object Model, used as the basis for all object binding), and ActiveX (COM enabled for the Internet). In addition to all of the DCOM capabilities, CORBA is applicable to other non-Windows operating systems. As stated earlier, applications built from components are simply easier to debug and evolve than large, monolithic applications.
The logical boundary for component applications is no longer on a single machine. Businesses want to leverage the benefits of component development across a broader set of shared applications that operate on multiple machines. These types of applications are referred to as “three-tier” or “n-tier” applications, where “tiers” of application logic, presentation services, business services, and information retrieval and management services, are broken into different components that can communicate directly with each other across a network. To the end user, these applications appear as a seamless extension of their existing desktop environment.
The simplicity, ubiquity, and industry momentum of standard Internet protocols like HTTP make it an ideal technology for linking components together for applications that span machine boundaries. HTTP is easy to program, is inherently cross-platform, and supports an accessible, universal naming service. Much of the excitement around the Java language derives from its potential as a mechanism to build distributed component applications on the Internet. In addition to Java support, CORBA enables components written in other languages, including C, COBOL, Basic, and Pascal, to communicate over the Internet, providing a growth path for existing applications to support Web technology.
As distributed component architectures, such as CORBA, are making their mark as a technology that enables software components to communicate directly with each other across networks, many businesses have a wealth of information that is managed by prior art data base management systems such as DMS, RDMS, DB2, Oracle, Ingres, Sybase, Informix, and many others. In addition, many of the database management systems are available as resources in a larger transaction processing system.
One key to the future success of a business may lie in its ability to capitalize on the ability to interconnect a distributed component architecture, such as CORBA, with existing enterprise systems having applications developed in accordance with the XATMI standard. It defeats the two main goals of component-based development, fast time-to-market and lower development costs, if companies are forced to “hand code” into their component applications the mission critical services that are required for online production systems. Therefore, the leading system suppliers have developed commercially available “middleware” to link web based work stations with existing XATMI systems.
However, most existing XATMI systems have been developed under the assumption that user work stations are physically, electrically, and functionally dedicated exclusively to providing communication between the XATMI and a single user during an entire user session period. This assumption arose at a time in which user work stations were simply dumb video display/keyboard devices connected directly to the XATMI mainframe via a dedicated electrical line.
Modern work stations, however, are extremely complex and capable of substantial unassisted data processing. Furthermore, the internet connection between a modern work station and the XATMI enterprise system is anything but physically, electrically, and functionally dedicated exclusively to a single user session.
A particular difficulty in structuring the conversion of CORBA requests is the need to initialize all potential CORBA objects upon start up of the server. This tends to slow the process and may be costly in terms of the resources which must be dedicated to the initialization.